Conventional building management systems BMS, also referred to as building control or building automation systems—these terms are interchangeably used in this application—are modeled in a three layer architecture comprising                a management layer as to which monitoring and control systems are associated        an automation layer to which controllers, gateways or the like are associated and        a field layer to which sensors, actuators or the like are associated.        
The management layer enables human interaction and configuration in daily operation. This top layer communicates with automation level gateway devices e.g. via ModBus, M-Bus, EEB, BACnet/IP or OPC protocols to access information from sensing and actuation devices. Typically conventional management level systems are referred to as SCADA. SCADA-like systems are applicable to controlling various kinds of service provisioning systems. Such systems provide specific services to requestors, e.g. heating, ventilation, cooling, water, etc. and are denoted “service systems” in the following. Service systems may share resources, e.g. a gas boiler may provide thermal energy supply to heating systems and hot water systems inside a single building. Thus service systems may be inter-dependent. Service systems may also be inter-dependent due to other reasons, e.g. the physical layout of the building: a room cooled by air conditioning may share a wall with a room being heated. Service systems' behaviors are controlled by the BMS automation and field layers under guidance of the management layer.
BMS have usually a large amount of different sensors, actuators and controllers. Operators of a BMS try to enhance the efficiency of the service systems to save costs, etc.
The specific optimization of a single service system (e.g. a heating, ventilation and air-conditioning system HVAC) or e.g. a single area (e.g. floor or single office area) with respect to one or more defined key performance indicators KPI lacks the consideration of side effects on other systems or areas of the entire building and can have adverse impacts on total energy consumption or other applications' KPIs. In the EU FP-7 research projects CAMPUS21 and BaaS, the developed supervisory single system heating control optimizations are examples of specialized conventional applications using a networked BMS via a standardized request interface.
In a conventional SCADA setting, human staff's changes to the operational parameters of a single system, e.g. the HVAC supply temperatures, can have effects on other areas. The effects of changes are hard to predict even for expert users. For example a change to a system operation schedule or an adaptation of a supply temperature set-point curve can have significant effects on other systems by unforeseen interdependencies.
In conventional building management settings, SCADA systems have configured with permissible ranges of allowed control parameters and use credentials to protect against changes of configuration or control pattern. However these ranges are set statically and do not dependent on the operational context. Due to this, conventional systems are over-dimensioned subject to a so-called coincidence factor describing the probability of coinciding requests/demands. If operational reality deviates from this, resource shortages occur. The dimensioning of service systems due to coincidence factor is a trade-off: conservative estimates ensure operations but come at the cost of over dimensioned systems while optimistic estimates run the risk of frequent shortages and conflicts.
For instance an installed boiler capacity of a building is dimensioned by a peak load of different heat consuming systems (HVAC, space heating, hot water, potentially special systems like grass heating) expected to coinciding at most. As system configurations change, usage patterns and weather change, as well as refurbishment measures, e.g. replacement of boilers or heat exchangers over the lifetime of a building, situations can arise where the expected coincidence does not match reality anymore. Two negative scenarios can be conceived:                1.) In case the heat supply capacity is insufficient, adverse effects or conflicts on all or only a subset of the systems are expected. Typically, these systems will react with increases in demand (e.g. by indicating increased system supply temperatures resulting in increased heat exchanger valve openings on the overall supply circuit) worsening the overall heating situation further.        2.) In situations where the installed heat supply peak capacity is just sufficient, the boiler may run outside of maximum efficiency operation ranges.        
In particular thermal systems such as space heating, hot water and cooling typically have much flexibility: e.g. indoor temperature controls usually aim at staying within a target temperature band (e.g. 20° C.±1° C.). Further by varying supply temperature set points they have flexibility in energy consumption and duration of operation.
In WO2013/171234 conflicts are detected and resolved by distributed orchestration engines hosted in e.g. PLC components. They detect that multiple conflicting requests have been received. The detected conflicts are communicated on a so-called service bus and are resolved by SCADA or Manufacturing Execution Systems (MES).
In U.S. Pat. No. 8,615,312 an orchestration engine is defined based on High Level Petri Nets (HLPN) defining the orchestration engine behavior to orchestrate service oriented service systems. No conflicts are resolved.
In US20110035229 also covers orchestration of services offered by service-oriented automation components of a manufacturing facility from one manufacturing level to a higher level such as the corporate, business and/or production level. No conflict resolution is described.
In US20130232267 resource requests in a communication network are resolved by applying policies to network flows based on the aggregated resource availability, e.g. using priorities and admitting or rejecting flows completely.
Further in U.S. Pat. No. 7,031,793 a method for conflict resolution is described among a plurality of controllers. By adapting the control instructions, e.g. based on mathematical models in a multi-tiered architecture conflicts are detected and resolved.
Even further in the non-patent literature of Ruta, M.; Scioscia, F.; Loseto, G.; Di Sciascio, E., “Semantic-Based Resource Discovery and Orchestration in Home and Building Automation: A Multi-Agent Approach,” in Industrial Informatics, IEEE Transactions on, vol. 10, no. 1, pp. 730-741, February 2014 doi: 10.1109/TIL2013.2273433 a multi agent based conflict mediation and resource orchestration on the agent level for building domotics is described between a home agent and a device agent. Conflicts for newly received requests are negotiated on the agent level and based on utility expressions defined upon service preferences, i.e. if one agent's requests directly interfere with another agent's preferences.
In the non-published patent application PCT/EP 2016/055997 a retrospective resp. reactive solution resolving conflicts on shared resources and inter-dependencies for building automation is described. The described conventional method therein monitors control requests from so-called requestors towards the automation infrastructure and compares the already served requests in combination with a newly received request against rules defining adverse situations. In case one or more of the adverse situation rules (ASR) is violated, it is investigated if a reduction of one or more of the requests (already served and the newly received) could prevent ASR violation. If at least one combination of reductions can be constructed, these will be communicated for approval to the respective requestors. If agreed by the requestors, the modified requests are enacted.